\(ce)Research Institute for Mathematical Sciences, Kyoto University
\(fg)
\(ce)Preface
\(set-page pp-preface)
\(fr)
Kyoto Common Lisp (KCL for short) is a full
implementation of the Common Lisp language described in
the \(fi)Common Lisp Reference Manual\(fr):
\(ce)\(fi)Common Lisp: The Language\(fr).
\(ce)by Guy L. Steele et al.
\(ce)Digital Press, 1984
All Common Lisp functions, macros, and special forms
are defined in KCL, though a few of them have
slightly different meanings from those described in the \(fi)Common Lisp
Reference Manual\(fr). All such differences are described in this
report: If a Common Lisp function (or macro or special
form) does not work as
described in the \(fi)Common Lisp Reference Manual\(fr) and if this report
does not describe the difference explicitly, then there must be a bug in
KCL. All Common Lisp variables and constants are
defined in KCL exactly as described in the \(fi)Common Lisp Reference Manual\(fr).
Currently, there are four major versions of KCL:
1. \(sm)KCL/AOS, under the AOS/VS operating system for Data General's ECLIPSE MV series machines.\(rm)
2. \(sm)KCL/VAX, under the Unix 4.2 bsd operating system for Digital Equipment Corporation's VAX 11 series machines.\(rm)
3. \(sm)KCL/SUN, under the Unix 4.2 bsd operating system for Sun Microsystems' Sun Workstation.\(rm)
4. \(sm)KCL/UST, under the Unix V (Uniplus' version) operating system for Sumitomo Electric Industries and Digital Computer Laboratory's Ustation E15.\(rm)
KCL/AOS is the original version of KCL, which was developed
at Research Institute for Mathematical Sciences (RIMS), Kyoto University,
with the cooperation of Nippon Data General Corporation. The other three
versions, which are collectively called \(fi)KCL on Unix\(fr),
are transplanted versions of KCL/AOS.
This report is intended to complement the \(fi)Common Lisp Reference
Manual\(fr). This report describes deviations of KCL from Common Lisp,
those features specific to KCL,
and the implementation-dependent functions of Common Lisp.
\(fg)
\(ce)Acknowledgements
\(set-page pp-acknowledgements)
\(fr)
The project of KCL was supported by many people affiliated with many
institutions. We are very grateful especially to the following people for
their contributions to the project of KCL.
First of all, we are grateful to the contributors of the design of Common Lisp.
Prof. Reiji Nakajima at RIMS, Kyoto University, provided us with
considerable encouragement and moral support.
Nippon Data General Corporation (NDG) helped us implement KCL/AOS. Mr. Teruo Yabe and Mr. Toshiyasu Harada joined us
during the first stage of the KCL project
and did a lot of coding. Mr. Takashi Suzuki and Mr. Kibo Kurokawa arranged
the joint project. NDG is now supporting the distribution of KCL/AOS.
Data General Corporation in the United States sent us
materials necessary to
implement a Common Lisp system, such as the preliminary drafts of the
Common Lisp reference manual and benchmark tests for Common Lisp. The benchmark tests are indebted to Dr. Richard Gabriel at Stanford
University.
Dr. Daniel Weinreb at Symbolics solved most of our questions about the
language specification. He also sent us the definition
of \(fp)rationalize\(ri 'rationalize)\(fr) written by Dr. Skef Wholey at CMU. We use this definition in KCL without any change.
Dr. Carl Hoffman at Symbolics checked the top-level of KCL and
gave us advices to improve KCL. He also found some bugs in KCL and
fixed them for us.
Mr. Naruhiko Kawamura at RIMS developed a Prolog system
using the earliest version of KCL/AOS. That was one of the first big projects with KCL and he found many bugs.
Mr. Takashi Sakuragawa at RIMS hacked with KCL/AOS and gave us many
advises concerning with those features specific to KCL.
Mr. Tatsuya Hagino at Edinburgh University developed Micro EMACS on
which FeCl2, the full-screen editor embedded in KCL/AOS, is based.
Mr. Kunihiko Nakamura at Kagawa University converted the assembly
language
version of Micro EMACS into the C language, which happened to become the
prototype of FeCl2.
Prof. Akinori Yonezawa at Tokyo Institute of Technology encouraged us
to port KCL/AOS onto VAX 11.
Mr. Etsuya Shibayama at Tokyo Institute of Technology helped us
while we were working with the VAX 11 at the Institute.
Hagiwara Laboratory at Kyoto University offered (and is offering) their
VAX 11 for finishing transplantation and maintaining KCL/VAX. We got also technical advises from people at Hagiwara Laboratory.
Prof. Shuji Doshita at Kyoto University offered the SUN Workstation at
his Laboratory and gave us
a lot of advises for transplantation to SUN Workstation.
Mr. Takashi Hattori at RIMS gave us useful information about Motorola
68000, the CPU chip of SUN Workstation.
NDG helped us build up the KROFF (\(fi)K\(fr)yoto \(fi)ROFF\(fr))
system, with which this report was produced. They offered the character
font sets from
which the font sets used in KROFF were constructed. We also received some
technical
advises from NDG about the output devise of KROFF, i.e., NDG's 5880 series
laser beam
printers. Incidentally, all the programs that constitute the KROFF system,
including tools
to maintain KROFF font sets, are written in the Common Lisp language
and are running
under KCL.
\(fg)
\(ce)Table of Contents
\(set-page pp-contents)
\(fr)
Insert the first page of "Table of Contents" here.
\(fg)
\(ce)Table of Contents (Cont.)
\(fr)
Insert the second page of "Table of Contents" here.
\(fg)
\(ce)Chapter 1. How to Start and End a KCL Session
\(set-page pp-1)
\(fr)
KCL on Unix is invoked by the Shell command \(fp)kcl\(fr).
\(reserve 2)\(fp)
% kcl
KCL (Kyoto Common Lisp) \(do-string (lisp-implementation-version))
\(fr)
\(fr)---------------------- \(fi)Note to KCL/AOS users\(fr) ----------------------
KCL/AOS is invoked by the CLI command \(fp)KCL\(fr).
\(reserve 2)\(fp)
) KCL
KCL (Kyoto Common Lisp) \(do-string (lisp-implementation-version))\(fr)
\(fr)--------------------------- \(fi)End of Note\(fr) ----------------------------
When invoked, KCL will print the banner
and initializes the system. The date in the KCL banner
identifies the revision of KCL. "\(fp)\(do-string (lisp-implementation-version))\(fr)" is the value of the
function \(fp)lisp-implementation-version\(ri 'lisp-implementation-version)\(fr).
If there exists a file named \(fp)init.lsp\(fr) in the current working
directory,
KCL successively evaluates the forms in the file,
immediately after the system initialization. The user may set up his or her own KCL environment
(e.g., the memory configuration) by \(fp)init.lsp\(fr).
After the initialization, KCL enters the \(fi)top-level loop\(fr) and
prints the prompt '\(fp)>\(fr)'.
\(fp)
>
\(fr)
The prompt indicates that KCL is now ready to receive a form from the terminal
and to evaluate it.
Usually, the current package (i.e., the value
of \(fp)*package*\(ri '*package*)\(fr)) is the \(fp)user\(fr) package, and the prompt appears
as above. If, however, the current package is other than the \(fp)user\(fr)
package, then the prompt will be prefixed by the package name.
\(fi)package-name\(fp)>\(fr)
To exit from KCL,
call the function \(fp)bye\(ri 'bye)\(fr) (or \(fp)by\(ri 'by)\(fr)).
\(reserve 3)\(fp)
>(bye)
Bye.
%
\(fr)
\(fr)---------------------- \(fi)Note to KCL/AOS users\(fr) ----------------------
In this report, we sometimes assume that KCL is invoked
from the Unix Shell. In particular, we use the standard prompt
of the Unix Shell '\(fp)%\(fr)' in most examples.
\(fr)--------------------------- \(fi)End of Note\(fr) ----------------------------
Alternatively, you may type ^D (control-D),
i.e., press the key D while pressing down the
CNTL key.
\(reserve 2)\(fp)
>^DBye.
%
\(fr)
The top-level loop of KCL is almost the same as that
defined in Section 20.2 of the \(fi)Common Lisp Reference
Manual\(fr). Since the input from the terminal is in line mode,
each top-level form should be followed by a newline. If more
than one values are returned by the evaluation of the top-level form,
the values will be printed successively. If no value is returned, then
nothing will be printed.
\(reserve 7)\(fp)
>(values 1 2)
1
2
>(values)
>
\(fr)
When an error is signalled, control will enter the break loop.
\(reserve 12)\(fp)
>(defun foo (x) (bar x))
foo
>(defun bar (y) (bee y y))
bar
>(foo 'lish)
Error: The function BEE is undefined.
Error signalled by BAR.
Broken at BAR.
>>
\(fr)
'\(fp)>>\(fr)' in the last line is the prompt of
the break loop. Like in the top-level loop,
the prompt will be prefixed by the current package name,
if the current package is other than the \(fp)user\(fr) package.
To go back to the top-level loop, type \(fp):q\(ri ':q)\(fr).
\(reserve 4)\(fp)
>>:q
Top level.
>\(fr)
See Section 5.4 for the details of the break loop.
In KCL on Unix, the terminal
interrupt (usually caused by typing ^C (control-C) or by
typing DELETE) is a kind of error. It breaks the running program and calls
the break level loop.
Example:
\(fp)
>(defun foo () (do () (nil)))
foo
>(foo)
^C
Correctable error: Console interrupt.
Signalled by DO.
Broken at FOO.
>>
\(fr)
\(fr)---------------------- \(fi)Note to KCL/AOS users\(fr) ----------------------
In KCL/AOS, the console interrupt caused by typing ^C (control-C)
followed by ^A (control-A)
is a kind of error. Typing ^C and ^A breaks the running program
and calls the break loop. On the other hand, the console interrupt
caused by ^C and ^B (control-B) will immediately terminate KCL.
\(reserve 12)
Example:
\(fp)
>(defun foo () (do () (nil)))
foo
>(foo)
^C^A
Correctable error: Console interrupt.
Signalled by DO.
Broken at FOO.
>>(foo)
^C^B
*ABORT*
CONSOLE INTERRUPT
ERROR: FROM PROGRAM
LEVEL 1
x,kcl
)\(fr)
\(fr)--------------------------- \(fi)End of Note\(fr) ----------------------------
\(fg)
\(ce)Chapter 2. Data Types
\(set-page pp-2)
\(fr)
KCL supports all Common Lisp data types exactly as defined in the
\(fi)Common Lisp Reference Manual\(fr). This chapter simply complements
Chapter 2 of the \(fi)Common Lisp Reference Manual\(fr), by
describing implementation dependent features of Common Lisp data
types. Each section in this chapter corresponds to the section in Chapter 2
of the \(fi)Common Lisp Reference Manual\(fr), with the same section title.
\(reserve 5)\(fg)
2.1. Numbers\(set-page pp-2-1)
2.1.1. Integers\(set-page pp-2-1-1)
\(fr)
Fixnums in KCL are those integers
in the range \(fp)-\(fr)(\(fp)2\(fr) to the power of \(fp)31\(fr)) to
(\(fp)2\(fr) to the power of \(fp)31\(fr))\(fp)-1\(fr),
inclusive. Other integers are bignums. Thus
\(fp)25\(fr) factorial (\(fp)25!\(fr))
\(fp)
15511210043330985984000000
\(fr)
is certainly a bignum in KCL.
Common Lisp constants related to integers have the following values
in KCL.
\(fp)
most-positive-fixnum = 2147483647 = \(fr)(\(fp)2\(fr) to the power of \(fp)31\(fr))\(fp)-1\(ri 'most-positive-fixnum)
most-negative-fixnum = -2147483648 = -\(fr)(\(fp)2\(fr) to the power of \(fp)31\(fr))\(ri 'most-negative-fixnum)
\(fp)
boole-1 = 3\(ri 'boole-1)
boole-2 = 5\(ri 'boole-2)
boole-and = 1\(ri 'boole-and)
boole-andc1 = 4\(ri 'boole-andc1)
boole-andc2 = 2\(ri 'boole-andc2)
boole-c1 = 12\(ri 'boole-c1)
boole-c2 = 10\(ri 'boole-c2)
boole-clr = 0\(ri 'boole-clr)
boole-eqv = 9\(ri 'boole-eqv)
boole-ior = 7\(ri 'boole-ior)
boole-nand = 14\(ri 'boole-nand)
boole-nor = 8\(ri 'boole-nor)
boole-orc1 = 13\(ri 'boole-orc1)
boole-orc2 = 11\(ri 'boole-orc2)
boole-set = 15\(ri 'boole-set)
boole-xor = 6\(ri 'boole-xor)
\(fr)
See Chapter 12 of the \(fi)Common Lisp Reference Manual\(fr) for their
meanings.
\(reserve 5)\(fg)
2.1.2. Ratios\(set-page pp-2-1-2)
\(fr)
There are no implementation-dependent features for ratios.
\(reserve 5)\(fg)
2.1.3. Floating-Point Numbers\(set-page pp-2-1-3)
\(fr)
KCL provides two distinct internal floating-point formats. One format
is \(fi)short\(fr); the other
is \(fi)single\(fr) and serves also as \(fi)double\(fr) and
\(fi)long\(fr). The data types
\(fp)single-float\(fr), \(fp)double-float\(fr), and \(fp)long-float\(fr)
are considered to be identical, but \(fp)short-float\(fr) is
distinct. An expression such
as \(fp)(eql 1.0s0 1.0d0)\(fr) is false, but
\(fp)(eql 1.0f0 1.0d0)\(fr) is true. Similarly,
\(fp)(typep 1.0L0 'short-float)\(fr) is false, but
\(fp)(typep 1.0L0 'single-float)\(fr) is true. For output purposes all
floating-point numbers are assumed to be of \(fi)short\(fr)
A lambda-expression with null lexical environment but with an implicit
block around it. This type of functions
typically appear when
\(fp)(defun\(ri 'defun) \(fi)function-name\(fr) \(fi)lambda-list\(fr) . \(fi)body\(fp))\(fr) is evaluated. In this case, \(fi)block-name\(fr) is identical to \(fi)function-name\(fr).
Causes the specified functions to be not traced any more. \(fi)function-name\(fr)s must be symbols and they are not evaluated. \(fp)untrace\(fr) returns a name list of those functions that were untraced by
the call to \(fp)untrace\(fr). If no \(fi)function-name\(fr) is given, \(fp)untrace\(fr) will untrace
all the currently traced functions and will return a list of their names.
Starts evaluating the \(fi)form\(fr) in the single-step mode. In this mode, before any form is evaluated,
the Stepper will print the form and prompt the user
for a Stepper command. The Stepper binds
the two variables \(fp)*print-level*\(ri '*print-level*)\(fr) and \(fp)*print-length*\(ri '*print-length*)\(fr)
both to \(fp)2\(fr), so that the current form may not occupy too much
space on the screen. A Stepper command will be executed when the user types
the single character for the command followed by the required
arguments, if any, and presses the newline key. If the user presses the newline key without having typed any character,
then the Stepper will assume that the Stepper command
\(fp)n\(fr) was abbreviated.
The Stepper commands are:
\(br)
\(fp)n\(fr) \(sm)Next. Evaluates the current form in the single-step mode.\(rm)
\(fp)s\(fr) \(sm)Skip. Evaluates the current form in the ordinary mode. The single-step mode will be resumed at completion
of the evaluation.\(rm)
\(fp)p\(fr) \(sm)Print. Pretty-prints the current form and then prompts again.\(rm)
\(fp)f\(fr) \(fi)fn\(fr) \(sm)Function. Evaluates the current form in the ordinary mode until the specified
function \(fi)fn\(fr) is invoked. If the specified function is not invoked at all, then this command has the same effects as the \(fp)q\(fr) command below.\(rm)
\(fp)q\(fr) \(sm)Quit. Evaluates the current form and any other forms in the ordinary mode.\(rm)
\(fp)e\(fr) \(fi)form\(fr) \(sm)Eval. Evaluates the specified form in the ordinary mode and prints the resulted values. Then prompts again with the same current form.\(rm)
\(fp)?\(fr) \(sm)Help. Lists the Stepper commands.\(rm)
This variable is used to determine whether to enter the
break loop (see Section 5.4) when an error occurs. Even the function
\(fp)break\(ri 'break)\(fr) checks this variable. Initially, this variable is set to \(fp)t\(fr), and thus
an error will invoke the break loop. If the value is \(fp)nil\(fr),
functions that cause fatal errors, such as \(fp)error\(ri 'error)\(fr),
will just print an error message and control will return to the top-level loop
(or to the current break loop, if already in the break loop). Functions
that cause correctable errors, such as \(fp)cerror\(ri 'cerror)\(fr),
will print an error message and a "continue message", and
control will return to the next form. In KCL, backtrace is not part of an error message, but
a break loop command will print backtrace. Therefore, if \(fp)*break-enable*\(ri '*break-enable*)\(fr) is \(fp)nil\(fr),
no backtrace appears on the screen.
When the break loop is entered, \(fp)*break-enable*\(ri '*break-enable*)\(fr)
will be bound to \(fp)nil\(fr).
\(endd)
\(reserve 5)\(fg)
5.4. The Break Loop\(set-page pp-5-4)
\(fr)
The break loop is a read-eval-print loop similar to the top-level loop. In addition to ordinary Lisp forms, the break loop accepts
various commands with which the user can inspect and modify the
state of the program execution. Each break loop command is identified
with a keyword (i.e., a symbol in the \(fp)keyword\(fr)
package). A break loop command is executed when the user inputs a list
whose first element is the keyword that identifies the command. The rest of the list is the arguments to the command. They are evaluated before passed to the command. If the command
needs no arguments, then the user may input only the keyword. It is an error if the given keyword does not identify any command. Any other input to the break loop is regarded as an
ordinary Lisp form; the form will be evaluated and the resulted values
will be printed on the terminal.
There can be several instances of the break loop at the same time, and
each such instance is identified by a \(fi)level
number\(fr). When the break loop is entered during execution in the
top-level loop,
the break loop instance is given the level number \(fp)1\(fr). The break loop instance that is entered from the level \(fi)n\(fr)
break loop is given the level number \(fi)n\(fp)+1\(fr). The prompt of the level \(fi)n\(fr) break loop is \(fi)n\(fp)+1\(fr)
consecutive \(fp)>\(fr)'s, occasionally prefixed with the name of
the current package.
The break loop keeps track of the invocation sequence of functions
(including special forms and macro expansion functions),
which led up to the break loop
from the previous break loop (or from the top-level loop,
if the current break loop is level \(fp)1\(fr)). The invocation sequence is maintained in a pushdown stack of \(fi)event\(fr)s. An event consists of an \(fi)event function\(fr) and an \(fi)event
environment\(fr). An event function is:
1. \(sm)an interpreted (i.e., not compiled) function (global function, local function, lambda-expression, or closure),\(rm)
2. \(sm)a special form within an interpreted function,\(rm)
3. \(sm)a macro expansion function called from an interpreted function,\(rm)
4. \(sm)a compiled function called from an interpreted function, or\(rm)
5. \(sm)a compiled function called from another compiled
function which was compiled while the \(fp)safety\(ri 'safety)\(fr) optimize
level is \(fp)3\(fr) or with a \(fp)notinline\(ri 'notinline)\(fr)
declaration for the called function (see Chapter 7).\(rm)
An event is pushed on the event stack when execution of its event
function begins, and is poped away at the completion of the
execution. An event environment is the 'environment' of the
event function at the time the next event is pushed. Actually, an event
environment is a pointer to
the main stack of KCL. For each interpreted event function (i.e., event
function in classes 1, 2, and 3),
the pointer points to the first entry of the three contiguous
main stack entries that hold the lexical environment of the event
function. For each compiled event function (i.e., event function in classes
4 and 5),
the pointer is set to the first entry of the
main stack area that is used locally by the compiled code. In most cases,
the first argument to the compiled function is saved in the
first entry, the second argument in the second entry, and so on. The local
variables of the function are allocated in the entries following the
arguments. However, this is not always the case. Refer to Section 7.3 for
variable allocations in compiled functions.
By break level commands,
the user can choose one of the events as \(fi)the current event\(fr). If the
current event function is an interpreted event function, then
the break loop evaluates Lisp forms
in the lexical environment retrieved from the event
environment. In particular, local variables may be referenced
by the variable names,
local functions and local macros may be invoked as usual, established
blocks may be exited from, and
tags may be used as the destination of \(fp)go\(ri 'go)\(fr). If the current function is a compiled function,
Lisp forms are evaluated in the null environment.
Within the break loop, each event is represented by \(fi)the event
symbol\(fr). The \(fp):backtrace\(fr)
command, for example, lists events in terms of their event symbols. If the event function is a named function (global or local)
or a macro expansion function, then the function or macro name
is used as the event symbol. If the event function is a special form,
then the name of the special form is used. If the event function is
a lambda-expression (or a closure), then the symbol \(fp)lambda\(fr) (or
\(fp)lambda-closure\(fr)) is used.
To suppress unnecessary information,
the user can hide (or make invisible) some of the events. Invisible events do not appear in the backtrace, for example. Initially, only those events are invisible whose event symbols belong to the
system internal package \(fp)system\(fr). When the break loop is entered,
the last visible event becomes the current event.
The break loop commands are described below. Some of the commands
allows abbreviation in the keywords that identify them. For example, the user may abbreviate \(fp):current\(fr) as \(fp):c\(fr). The break loop commands return no values at all.
in an interactive manner. The output of \(fp)inspect\(fr) is similar to that of \(fp)describe\(fr),
but after printing the label and the value of a field
(the value itself is not \(fp)describe\(fr)'d),
it prompts the user to input a one-character command. The input to \(fp)inspect\(fr) is taken from the stream
that is the value of \(fp)*query-io*\(ri '*query-io*)\(fr). Normally, the
inspection of \(fi)object\(fr) terminates
after all of its fields have been inspected. The following commands are
supported:
\(br)
\(fp)n\(fr) \(sm)Next. Goes to the next level; the field is inspected recursively.\(rm)
\(fp)s\(fr) \(sm)Skip. Skips the inspection of the field. \(fp)inspect\(fr) proceeds to the next field.\(rm)
\(fp)p\(fr) \(sm)Print. Pretty-prints the field and prompts again.\(rm)
\(fp)u \(fi)form\(fr) \(sm)Update. The \(fi)form\(fr) is evaluated and the field is replaced by the resulted value. If the field cannot be updated, the message \(fp)Not updated.\(fr) will be printed.\(rm)
\(fp)a\(fr) \(sm)Abort. Aborts the inspection of the current object. The field and the rest of the fields are not inspected.\(rm)
\(fp)e \(fi)form\(fr) \(sm)Eval. Evaluates the specified form in the null environment and prints the resulted values. Then prompts again with the same field.\(rm)
\(fp)q\(fr) \(sm)Quit. Aborts the entire inspection.\(rm)
\(fp)?\(fr) \(sm)Help. Lists the \(fp)inspect\(fr) commands.\(rm)
\(endd)
\(fg)
\(ce)Chapter 6. The Compiler
\(set-page pp-6)
\(fr)
The KCL compiler translates a Lisp program stored
in a source file
into a C-language program, invokes the C-language compiler to compile
the C-language program, and then generates an object file, called
\(fi)fasl file\(fr) (or \(fi)o-file\(fr) because of the actual filetype). The compiled program in a fasl file is loaded by
the function \(fp)load\(ri 'load)\(fr).
Ordinarily, the object program generated by the KCL compiler scarcely
does runtime
error-checking for runtime efficiency. In addition, Lisp functions in the
same source file are linked together and some system functions are
open-coded in-line. To control runtime error checking, supply
appropriate \(fp)optimize\(fr) declarations (see Section 7.1).
The KCL compiler processes
the \(fp)eval-when\(ri 'eval-when)\(fr) special form
exactly as specified in the \(fi)Common Lisp Reference
Manual\(fr). However, all top-level forms in the source file are normally
processed in \(fi)compile-time-too\(fr) mode, not
in \(fi)not-compile-time\(fr) mode (see Section 5.3.3 of the
\(fi)Common Lisp Reference Manual\(fr)). That is, each top-level form
\(fi)top-level-form\(fr) is processed as if it were surrounded by the
\(fp)eval-when\(fr) special form with the situations \(fp)compile\(fr),
Terminates KCL and returns the \(fi)exit-code\(fr) to the parent process. \(fi)exit-code\(fr) must be an integer and its default value is \(fp)0\(fr).
\(endd)
\(fr)---------------------- \(fi)Note to KCL/AOS users\(fr) ----------------------
The functions \(fp)bye\(fr) and \(fp)by\(fr) of KCL/AOS accept a string
instead of an \(fi)exit-code\(fr). If \(fi)string\(fr) is supplied, these functions return the \(fi)string\(fr) to the father as the termination message.
\(fr)--------------------------- \(fi)End of Note\(fr) ----------------------------
The following functions \(fp)process\(ri 'process)\(fr),
\(fp)termination-message\(ri 'termination-message)\(fr), and
This function is defined only in KCL/AOS. \(fp)process\(fr) creates a process in the way as specified by
its arguments.
\(fi)progname\(fr) \(sm)The name of the process to create. Must be a string.\(rm)
\(fi)ipc-message\(fr) \(sm)The IPC message passed to the process. Must be a string. Arguments in the message must be separated with commas '\(fp),\(fr)'.\(rm)
\(fp):block\(fr) \(sm)If non-\(fp)nil\(fr), KCL blocks its execution while the son executes. Defaults to \(fp)t\(fr).\(rm)
\(fp):console\(fr) \(sm)The name of the file to be associated to \(fp)@console\(fr). Must be a string. No file is associated if \(fp):console\(fr) is not specified and if the \(fp):ioc\(fr) argument (see below) is specified with a non-\(fp)nil\(fr) value. \(fp):console\(fr) supercedes \(fp):ioc\(fr).\(rm)
\(fp):debug\(fr) If non-\(fp)nil\(fr), the son runs in the debug mode.
\(fp):input\(fr) \(sm)The name of the file to be associated to \(fp)@input\(fr). Must be a string. No file is associated if \(fp):input\(fr) is not specified and if the \(fp):ioc\(fr) argument (see below) is specified with a non-\(fp)nil\(fr) value. \(fp):input\(fr) supercedes \(fp):ioc\(fr).\(rm)
\(fp):output\(fr) \(sm)The name of the file to be associated to \(fp)@output\(fr). Must be a string. No file is associated if \(fp):output\(fr) is not specified and if the \(fp):ioc\(fr) argument (see below) is specified with a non-\(fp)nil\(fr) value. \(fp):output\(fr) supercedes \(fp):ioc\(fr).\(rm)
\(fp):username\(fr) \(sm)The user-name of sub-process. Must be a string. If not specified, the current user-name is used.\(rm)
\(fp):list\(fr) \(sm)If a string, the name of the file to be associated to \(fp)@list\(fr). If \(fp)t\(fr), the file currently associated to \(fp)@list\(fr) is used. If \(fp)nil\(fr), or if not specified, no list file is passed to the son.\(rm)
\(fp):data\(fr) \(sm)If a string, the name of the file to be associated to \(fp)@data\(fr). If \(fp)t\(fr), the file currently associated to \(fp)@data\(fr) is used. If \(fp)nil\(fr), or if not specified, no data file is passed to the son.\(rm)
\(fp):ioc\(fr) \(sm)If non-\(fp)nil\(fr), current \(fp)@input\(fr), \(fp)@output\(fr), and \(fp)@console\(fr) files are passed to the son. If not specified, these files are not passed unless specified by the \(fp):console\(fr), \(fp):input\(fr), or \(fp):output\(fr) arguments.\(rm)
This function is defined only in KCL/AOS. \(fp)termination-message\(fr) returns a string consisting of the termination message of a son. Used in connection with the function \(fp)process\(fr).
\(fp)defentry\(fr) defines a Lisp function whose body consists of
the calling sequence to a
C-language function. \(fi)function\(fr) is the name of the Lisp function
to be defined, and\(fi) C-function\(fr) specifies the C function
to be invoked. \(fi)C-function\(fr) must be either a list
\(fp)(\(fi)type\(fp) \(fi)C-id\(fp))\(fr) or \(fi)C-id\(fr),
where \(fi)type\(fr) and \(fi)C-id\(fr) are the type and
the name of the C function. \(fi)type\(fr) must be a C-type or
the symbol \(fp)void\(fr) which means that the C function returns
no value. \(fp)(object \(fi)C-id\(fp))\(fr) may be abbreviated
as \(fi)C-id\(fr). \(fi)parameter-list\(fr) is a list of C-types
for the parameters of the C function. For example,
the following \(fp)defentry
\(fr)form defines a Lisp function \(fp)tak\(fr) from
which the C function \(fp)tak\(fr) above is called.
\(fp)
(defentry tak (int int int) (int tak))
\(fr)
The Lisp function \(fp)tak\(fr) defined by this \(fp)defentry\(fr) form
requires three arguments. The arguments are converted to
\(fp)int\(fr) values before they are passed to the C function. On return
from the C
function, the returned \(fp)int\(fr) value is converted
to a Lisp integer (actually a fixnum)
and this fixnum will be returned as the value
of the Lisp function. See below for
type conversion between Lisp and the C language.
A \(fp)defentry\(fr) form is treated in the above way only when it appears as a top-level form of a Lisp source file. Otherwise, a \(fp)defentry\(fr) form expands to \(fp)nil\(fr).
\(fp)defCfun\(fr) defines a C-language function which calls
Lisp functions and/or which
handles Lisp objects. \(fi)header\(fr) is a string consisting of the C
code for
\(reserve 3)
the optional \(fi)type-specifier\(fr) of the C function,
the \(fi)function-declarator\(fr) of the C function, and
the \(fi)type-decl-list\(fr) of the parameters to the C function.
(For the C-language terminology, refer to \(fi)The C Programming Language\(fr) by Brian W. Kernighan and Dennis M. Ritchie.) The rest of the C function
definition, i.e., the
\(fi)function-statement\(fr), is given by\(fi) element\(fr)s. Each \(fi)element\(fr) may be a string, in which case
the string is treated in the same way as the arguments to the \(fp)Clines\(fr) macro. Or else,
the \(fi)element\(fr) is a list
\(fp)((\(fi)name arg1\(fr) ... \(fi)argn\(fp)) \(fi)place1\(fr) ... \(fi)placem\(fp))\(fr). The compiler
translates this list into a calling sequence to the Lisp function
whose name is \(fi)name\(fr). As will be
mentioned later, \(fi)name\(fr) may be \(fp)quote\(ri 'quote)\(fr),
but \(fi)name\(fr) may not be the name of other special
form or a macro. The \(fi)arg\(fr)s specify the arguments to the function
and the \(fi)place\(fr)s
specify where the values should go. Thus the list-formed \(fi)element\(fr) could be regarded
Each \(fi)arg\(fr) is a list\(fp) (\(fi)C-type\(fp) \(fi)C-expr\(fp))\(fr), where \(fi)C-expr\(fr) is any C-language expression of the
type \(fi)C-type\(fr). If \(fi)type\(fr) is \(fp)object\(fr), then \(fi)arg\(fr) may be written simply as \(fi)C-expr\(fr). Similarly,
each \(fi)place\(fr) is a list\(fp) (\(fi)C-type\(fp) \(fi)C-expr\(fp))\(fr), or it may be abbreviated as\(fi) C-expr\(fr) if \(fi)C-type\(fr) is
\(fp)object\(fr). The \(fi)C-expr\(fr) in this case is any \(fi)lvalue\(fr) (in the terminology of the C
language), i.e., it may be any valid C-language code that can be written at the left
side of an assignment.
The function call is performed as follows. The \(fi)arg\(fr)s are evaluated, and the
values are sent to the specified Lisp function after type conversion from C to Lisp. On return from the called Lisp function, each returned value is assigned to the
corresponding \(fi)place\(fr), i.e., the first returned value goes to \(fi)place1\(fr), the second to \(fi)place2\(fr),
and so on. If there are more \(fi)place\(fr)s than the values returned, extra values of \(fp)nil
\(fr)are assigned to the remaining \(fi)place\(fr)s. If there are more values than \(fi)place\(fr)s, the
excess values are simply discarded. If necessary, Lisp-to-C type conversion may
take place before each returned value is assigned.
If the Lisp function is called just for side-effects, then the list-formed \(fi)element
\(fr)may be abbreviated as a one-level list\(fp) (\(fi)name\(fp) \(fi)arg1\(fr) ... \(fi)argn\(fp))\(fr).
As a special case, if a list-formed \(fi)element\(fr) is of the form\(fp) ((quote \(fi)value\(fp)) \(fi)place\(fr)),
the Lisp object \(fi)value\(fr) is assigned to \(fi)place\(fr). Here \(fi)value\(fr) may be any Lisp object.
The following \(fp)defCfun\(fr) form defines the C function\(fp) silly\(fr) which adds \(fp)100\(fr) to
the value of the parameter \(fp)x\(fr) and prints the result in three different ways. The
second argument to\(fp) defCfun\(fr) will be described later, and the user may ignore it.
\(reserve 8)\(fp)
(defCfun "silly(x) int x;" 0
% int y;
((+ (int x) (int "100")) (int y))
% printf("\\n%d", y);
% y = x+100;
(print (int y))
(print (int "x+100"))
)
\(fr)
When a C function handles Lisp objects (i.e., data of type \(fp)object\(fr)), the user
should be careful enough so that the objects may not be garbage-collected. This is
because the garbage collector of KCL does not take care of Lisp objects used in the
C function. See the following C function which is assumed to return a two-element
list consisting of its two arguments.
\(reserve 7)\(fp)
(defCfun "object list2(x,y) object x,y;" 0
% object z;
('nil z)
((cons y z) z)
((cons x z) z)
% return(z);
)
\(fr)
When invoked, \(fp)list2\(fr) first sets \(fp)nil\(fr) to the variable \(fp)z\(fr), conses \(fp)y\(fr) to \(fp)z\(fr), and then conses
\(fp)x\(fr). Each time \(fp)cons\(fr) is called, a new cons cell is allocated and the pointer to this cell
is stored in \(fp)z\(fr). However, there is no way to inform
the garbage collector that the cells are referenced from the C variable \(fp)z\(fr). Suppose
that the cons cell allocated by the first \(fp)cons\(fr) is the last cons cell available at that
time. Then, during execution of the second call to \(fp)cons\(fr), the garbage collector
begins to run and, unfortunately, the cons cell in \(fp)z\(fr) will be destroyed so that the
cell can be recycled for further use.
To prevent a Lisp object from being unexpectedly garbage collected, the user
must save the object in some place that is recognized by the garbage collector. The
second parameter \(fi)n\(fr) to \(fp)defCfun\(fr) is used to reserve \(fi)n\(fr) such places for each call to the
C function. In the body of the C function, these reserved places are referenced as
\(fp)vs[0]\(fr), ..., \(fp)vs[\(fi)n-1\(fp)]\(fr). The function \(fp)list2\(fr) above, therefore, should be revised as
\(fp)\(fr)follows.
\(reserve 6)\(fp)
(defCfun "object list2(x,y) object x,y;" 1
('nil "vs[0]")
((cons y "vs[0]") "vs[0]")
((cons x "vs[0]") "vs[0]")
% Creturn(vs[0]);
)
\(fr)
Notice that \(fp)return\(fr) is replaced by \(fp)Creturn\(fr). \(fp)Creturn\(fr) is similar to \(fp)return\(fr) except
that \(fp)Creturn\(fr) releases the reserved places on
return from the function. In the C
code within a \(fp)defCfun\(fr) form,
write "\(fp)Creturn(\(fi)value\(fp));\(fr)" instead of
"\(fp)return(\(fi)value\(fp));\(fr)", and
write "\(fp)Cexit;\(fr)" instead of "\(fp)return;\(fr)".
Again, a \(fp)defCfun\(fr) form has the above meaning only when it appears as a top-level form in a Lisp source file. Otherwise, the form expands to \(fp)nil\(fr).\(endd)
KCL converts a Lisp object into a C-language data by using the Common Lisp function
\(fp)coerce\(ri 'coerce)\(fr): For the C-type \(fp)int\(fr) (or \(fp)char\(fr)), the object is first coerced to a Lisp integer and
the least significant 32-bit (or 8-bit) field is used as the C \(fp)int\(fr) (or \(fp)char\(fr)). For the C-type \(fp)float\(fr) (or \(fp)double\(fr)), the object is coerced to a short-float (or a long-float) and this
value is used as the C \(fp)float\(fr) (or \(fp)double\(fr)). Conversion from a C data into a Lisp object is
obvious: C \(fp)char\(fr), \(fp)int\(fr), \(fp)float\(fr), and \(fp)double\(fr) become the equivalent Lisp character, fixnum,
short-float, and long-float, respectively.
Here we list the complete syntax of \(fp)Clines\(fr), \(fp)defentry\(fr), and \(fp)defCfun\(fr) macro forms.
as a \(fi)C\(fr)ommon \(fi)L\(fr)isp \(fi)TOO\(fr)l). FeCl2 is an EMACS-like editor with facilities for Lisp coding. FeCl2 is invoked from KCL by the function \(fp)ed\(ri 'ed)\(fr)
and the result of editing can be passed to KCL directly. For the details of FeCl2 refer to \(fi)The FeCl2 Editor Reference Manual\(fr).
and sets the edit file of FeCl2 to \(fi)filename\(fr). If the filetype of the file is not explicitly specified,
then the \(fi)filename\(fr) is
first merged into \(fp)#".lsp"\(fr).
\(endd)
The FeCl2 editor is not supported by other versions of KCL. The function \(fp)ed\(fr) of KCL/VAX, KCL/SUN, and KCL/UST calls the vi editor. If you hate vi, define your own \(fp)ed\(fr) function using the function
\(fp)system\(ri 'system)\(fr) described in Chapter 8.
\(fg)
\(ce)Appendix A. KCL Summary
\(set-page pp-summary)
\(fr)
The following table lists all symbols defined in KCL. Each line has one of the
following form.
\(fi)symbol\(fr) [\(fi)kind\(fr)] \(fi)remark
\(fr)
where \(fi)kind\(fr) is Function, Macro, Special (i.e., Special form name),
Variable, Constant, Symbol, or Keyword. In the table, some symbols are
indicated both as a macro and a special form name. This means
that, although these symbols are defined to be a macro name
in the \(fi)Common Lisp Reference Manual\(fr), KCL treats them as
if they were special forms (see Section 9.1). The pages in the remark
refer to pages in this report.
\(load 'summary.lsp)
\(fg)
\(ce)Appendix B. An Overview of Kyoto Common Lisp
\(set-page pp-overview)
\(fr)
\(fi)Kyoto Common Lisp\(fr) (KCL for short) is a full implementation of the
Common
Lisp language. KCL is a highly portable Common Lisp system intended for
several classes of machines, from mini/micro to mainframe. The key idea
behind the portability is the use of the C language and its standard libraries
as the interface with
the underlying machines and operating systems: The kernel of the system
is written in C and the rest of the system is written in Common
Lisp. Even the compiler generates intermediate code in C. KCL is also
an efficient and compact system: KCL regards the runtime efficiency of
interpreted code as important as the efficiency of compiled code. The small
size of the KCL system makes KCL suitable for the current computer technology,
such as the use of virtual memory and cache memory. This document reports
the current status of KCL, its
implementation, and system performance. This document is a draft:
the description is still incomplete and informal,
and some technical terms are used without
definition or explanation. A full paper on the KCL implementation is in
preparation.
\(reserve 5)\(fg)
KCL is a full Common Lisp system.
\(fr)
KCL is a full implementation of the Common Lisp language described in
the \(fi)Common Lisp Reference Manual\(fr):
\(ce)\(fi)Common Lisp: The Language\(fr).
\(ce)by Guy L. Steele et al.
\(ce)Digital Press, 1984
KCL supports all Common Lisp functions, macros, and special forms defined
in the \(fi)Common Lisp Reference Manual\(fr). All Common Lisp variables
and constants are defined in KCL exactly as
described in the \(fi)Common Lisp Reference Manual\(fr).
\(reserve 5)\(fg)
KCL is available on several machines already.
\(fr)
Currently, there are four major versions of KCL:
1. KCL/AOS
Machine: \(sm)Data General's Eclipse MV series super-minicomputers (MV10000, MV8000, MV6000, and MV4000)\(rm)
Operating System: \(sm)Data General's original AOS/VS (Advanced Operating System / Virtual Storage)\(rm)
2. KCL/VAX
Machine: \(sm)Digital Equipment Corporation's VAX 11 series machines (VAX 11/780 and VAX 11/750)\(rm)
Operating System: UNIX 4.2 bsd
3. KCL/SUN
Machine: \(sm)Sun Microsystems' Sun Workstation (MC68000 base)\(rm)
Operating System: UNIX 4.2 bsd
4. KCL/UST
Machine: \(sm)Sumitomo Electric Industries and Digital Computer Laboratory's personal workstation Ustation E15 (MC68000 base)\(rm)
Operating System: UNIX V (Uniplus' version)
KCL/AOS is the original version of KCL, which was developed
at Research Institute for Mathematical Sciences (RIMS), Kyoto University,
with the cooperation of Nippon Data General Corporation. Other versions are
ported from KCL/AOS at RIMS. All four versions share most of the source
files of KCL. Improvements and error corrections are performed on
the common source files, and the most recent revisions are brought to each
machine from time to time.
Ports to other machines
and other operating systems are being undertaken or in preparation
at other organizations. KCL is expected to become available on the following
machines in the near future.
* IBM (and IBM-compatible) M series machines
* Apollo Domain
* Perkins Elmer
* VAX 11 (running VMS)
* VAX 11 (running Eunice, the Unix emulator)
* Eclipse MV (running DGUX, Data General's native Unix)
\(reserve 5)\(fg)
KCL is written in C and Lisp
\(fr)
The kernel of KCL is written in C, including:
* memory management and garbage collection
* the evaluator (or interpreter)
* Common Lisp special forms
The KCL compiler is entirely written in Common Lisp.
Each Common Lisp function or macro is written either in C or in Lisp.
\(reserve 3)
in C:
418 Common Lisp functions
11 Common Lisp macros
\(reserve 3)
in Lisp:
133 Common Lisp functions
59 Common Lisp macros
The size of the source code is:
\(reserve 6)
C code 705 Kbytes
Common Lisp functions and macros written in Lisp
173 Kbytes
The compiler 264 Kbytes
\(fs)-------------------------\(fr)
total 1142 Kbytes
Three routines in the kernel are partly written
in assembly language. These routines are:
* bignum multiplication
* bignum division
* \(sm)bit table manipulation of the garbage collector\(rm)
The total size of assembly code is 20 to 30 lines, depending on the
version of KCL.
\(reserve 5)\(fg)
KCL/AOS is built up by old-fashioned bootstrapping
\(fr)
When KCL/AOS, the original version of KCL, was born, the following steps
were taken to build it up.
1. \(sm)Compile all C code with the C compiler and link them
all. A subset of KCL is ready to run at this moment.\(rm)
2. \(sm)Load all Lisp code into KCL. Now the full system is ready
to run, although the compiler and some Common Lisp functions and macros
run interpretively.\(rm)
3. \(sm)Compile the source files of the KCL compiler
with the (interpreted) KCL compiler itself. Load each Fasl-file (i.e., the
file created by the KCL compiler) immediately
after it is generated. The compilation process becomes faster
toward the end of this step. Finally, the whole KCL compiler is ready
to run by itself.\(rm)
4. \(sm)Compile the Common Lisp functions and macros written in Lisp,
with the compiled KCL compiler. Load the Fasl-files. This completes
the generation of the full system.\(rm)
The same steps are taken whenever drastic changes are made
to the kernel. On the other hand, the procedure to port KCL or to
revise the ported versions of KCL is much simpler, because all Lisp code has
been cross-compiled by the compiler of KCL/AOS beforehand.
\(reserve 5)\(fg)
Objects are represented by cells.
\(fr)
KCL does not support the so-called immediate data. Any KCL object is
represented as (a pointer to) a cell that is allocated on the heap. Each
cell consists of several words (1 word = 32 bit) whose first word is in the
format common to all data types: half of the word
is the type indicator and the other half
is used as the mark by the garbage collector. For instance, a cons cell
consists of three words:
\(reserve 7)\(fp)
\(fs)1----------2-----------3\(fp)
| 'CONS' | mark-bit \(fs)|
\(fs)4----------8-----------6\(fp)
| car-pointer \(fs)|
\(fs)4----------------------6\(fp)
| cdr-pointer \(fs)|
\(fs)7----------------------9\(fp)
\(fr)
and a fixnum cell consists of two words:
\(reserve 5)\(fp)
\(fs)1----------2-----------3\(fp)
| 'FIXNUM' | mark-bit \(fs)|
\(fs)4----------8-----------6\(fp)
| fixnum-value \(fs)|
\(fs)7----------------------9\(fp)
\(fr)
Array headers and compiled-function headers are represented in this way, and
array elements and compiled code are placed elsewhere.
Internally in compiled functions, certain Lisp objects
may be represented simply by their values. For example, a fixnum object
may be represented by its fixnum value, and a character object
may be represented by its character code.
Cells of small fixnums ranging from \(fp)-1024\(fr) to \(fp)1023\(fr) and
cells of characters
are pre-allocated in fixed locations. Thus, for example,
\(fp)
(eq 1023 1023)
\(fr)
yields \(fp)t\(fr), whereas
\(fp)
(eq 1024 1024)
\(fr)
yields \(fp)nil\(fr).
\(reserve 5)\(fg)
The heap is divided into pages.
\(fr)
The whole heap of KCL is divided into pages (1 page = 2048 bytes). Each page
falls in one of the following classes:
* pages that contain cells consisting of the same number of words
* pages that contain binary data such as compiled function code
* pages that contain relocatable data such as array elements
Free cells (i.e., those cells that are not used any more) consisting of the
same number of words are linked together to form a free list. When a new
cell is requested, the first cell in the free list (if it is not empty)
is used and is removed from the list. If the free list is empty, then the
garbage collector begins to run to collect unused cells. If the new
free list is too short after the garbage collection,
then new pages are allocated dynamically. Free
binary data are also linked together in the order of the size
so that, when a binary datum is being allocated on the heap, the smallest
free area that is large enough to hold the binary datum
will be used. Cell pages are never compactified. Once a page
is allocated for cells with
\(fi)n\(fr) words, the page is used for cells with \(fi)n\(fr) words only,
even after all the cells in the page become garbage. The same rule holds for
binary pages. In contrast, relocatable pages are sometimes
compactified. That is, each relocatable datum may be moved to another place.
\(ce)Appendix C. Kyoto Common Lisp Installation Guide
\(set-page pp-installation)
\(fr)
This appendix explains how to install the KCL system, separately for
each version of KCL.
\(reserve 5)\(fg)
C.1. Installation of KCL/AOS\(set-page pp-install-aos)
\(fr)
\(reserve 3)
1. Prepare a directory (hereafter called \(fi)KCL directory\(fr)) for Kyoto Common
Lisp. In the following examples, we suppose that the KCL directory is
\(fp):UDD:KCL\(fr).
\(reserve 3)
2. Load the distribution tape to the KCL directory.
\(reserve 3)\(fp)
) DIR
:UDD:KCL
) LOAD
\(fr)
You will find that the subdirectory \(fp)PORT\(fr) has been created. The \(fp)PORT\(fr) subdirectory contains everything that is needed to run KCL. Files in this directory are:
\(reserve 2)
Documents:
\(fp)README\(fr) this file
\(reserve 5)
Executable files:
\(fp)KCL.PR\(fr) the KCL interpreter and compiler
\(fp)KCL.ST\(fr)
\(fp)BUILD_FASL.PR\(fr) the fasl-file builder
\(fp)FECL2.PR\(fr) the FeCl2 editor
\(reserve 5)
Command files:
\(fp)KCL.CLI\(fr) to invoke KCL
\(fp)LC.CLI\(fr) to invoke the KCL compiler
\(fp)LC1.CLI\(fr) to invoke the KCL compiler
\(fp)FECL2.CLI\(fr) to invoke the FeCl2 editor
\(reserve 2)
Header file:
\(fp)CMPINCLUDE.H\(fr) the header file for the KCL compiler
\(reserve 2)
Miscellaneous:
\(fp)FECL2.CMD\(fr) FeCl2 editor command table
\(reserve 3)
3. Customize the command files.
The command file \(fp)KCL.CLI\(fr) consists of the following command lines
to invoke the KCL interpreter.
\(reserve 4)\(fp)
push;prom pop
sea :usr:dgc [!sea]
x :udd:[!user]:port:%0-% :udd:[!user]:port:
pop
\(fr)
Replace the two occurrences of "\(fp)[!user]\(fr)" with the name of the KCL directory
(i.e., \(fp)KCL\(fr) in our example).
\(reserve 4)\(fp)
push;prom pop
sea :usr:dgc [!sea]
x :udd:KCL:port:%0-% :udd:KCL:port:
pop
\(fr)
And move this file to an appropriate command directory, say \(fp):UTIL,\(fr) so
that all KCL users can access it.
If the name of the directory that includes DG's C compiler is not
\(fp):USR:DGC\(fr), you should replace it with the appropriate directory name,
so that the KCL compiler can access the C compiler by \(fp)CC.PR\(fr).
You can use the commands \(fp)LC.CLI\(fr) and \(fp)LC1.CLI\(fr) to invoke the compiler directly
Customize these command files in the same way as for the \(fp)KCL.CLI\(fr) command file
above.
\(reserve 3)
4. Install the header file
Copy the header file \(fp)CMPINCLUDE.H\(fr) to the standard directory for C include
files, say \(fp):USR:DGC\(fr).
\(reserve 5)\(fg)
C.2. Installation of KCL/VAX\(set-page pp-install-vax)
\(fr)
\(reserve 3)
1. Prepare a directory (hereafter called \(fi)KCL directory\(fr)) for Kyoto Common
Lisp. In the following examples, we suppose that the KCL directory is
\(fp)/usr/kcl\(fr).
\(reserve 3)
2. Load the distribution tape to the KCL directory.
\(reserve 3)\(fp)
% pwd
/usr/kcl
% tar x
\(fr)
You will find that the subdirectory \(fp)unixport\(fr) has been created. The \(fp)unixport\(fr) subdirectory contains everything that is needed to run KCL and
the KCL compiler. Files in this directory are:
\(reserve 2)
Documents:
\(fp)readme\(fr) this file
\(reserve 2)
Executable files:
\(fp)saved_kcl\(fr) the KCL interpreter and compiler
\(reserve 4)
Command files:
\(fp)kcl\(fr) to invoke KCL
\(fp)lc\(fr) to invoke the KCL compiler
\(fp)lc1\(fr) to invoke the KCL compiler
\(reserve 2)
Header file:
\(fp)cmpinclude.h\(fr) the header file for the KCL compiler
\(reserve 3)
3. Customize the command files.
The command file \(fp)kcl\(fr) consists of a single line command to invoke the KCL
interpreter.
\(reserve 2)\(fp)
#
~/unixport/saved_kcl ~/unixport/
\(fr)
Replace two '\(fp)~\(fr)'s with the pathname of the KCL directory (i.e., \(fp)/usr/kcl\(fr) in our example).
\(reserve 2)\(fp)
#
/usr/kcl/unixport/saved_kcl /usr/kcl/unixport/
\(fr)
And move this file to an appropriate command directory, say \(fp)/usr/bin\(fr), so
that all KCL users can access it.
You can use the commands \(fp)lc\(fr) and \(fp)lc1\(fr) to invoke the compiler directly from the
shell. The content of \(fp)lc\(fr) is:
\(reserve 3)\(fp)
#
echo Compiling $1.lsp
~/unixport/saved_kcl ~/unixport/ $1 $1 U1000
\(fr)
Customize these command files in the same way as for the kcl command file
above.
\(reserve 3)
4. Install the header file
Copy the header file \(fp)cmpinclude.h\(fr) to the standard directory for C include
files, say \(fp)/usr/include\(fr).
\(reserve 5)\(fg)
C.3. Installation of KCL/SUN\(set-page pp-install-sun)
\(fr)
\(reserve 3)
1. Prepare a directory (hereafter called \(fi)KCL directory\(fr)) for Kyoto Common
Lisp. In the following examples, we suppose that the KCL directory is
\(fp)/usr/kcl\(fr).
\(reserve 3)
2. Load the distribution tape to the KCL directory.
\(reserve 3)\(fp)
% pwd
/usr/kcl
% tar x
\(fr)
You will find that the subdirectory \(fp)unixport\(fr) has been created. The \(fp)unixport\(fr) subdirectory contains everything that is needed to run KCL and
the KCL compiler. Files in this directory are:
\(reserve 2)
Documents:
\(fp)readme\(fr) this file
\(reserve 2)
Executable files:
\(fp)saved_kcl\(fr) the KCL interpreter and compiler
\(reserve 4)
Command files:
\(fp)kcl\(fr) to invoke KCL
\(fp)lc\(fr) to invoke the KCL compiler
\(fp)lc1\(fr) to invoke the KCL compiler
\(reserve 2)
Header file:
\(fp)cmpinclude.h\(fr) the header file for the KCL compiler
\(reserve 3)
3. Customize the command files.
The command file \(fp)kcl\(fr) consists of a single line command to invoke the KCL
interpreter.
\(reserve 2)\(fp)
#
~/unixport/saved_kcl ~/unixport/
\(fr)
Replace two '\(fp)~\(fr)'s with the pathname of the KCL directory (i.e., \(fp)/usr/kcl\(fr) in
our example).
\(reserve 2)\(fp)
#
/usr/kcl/unixport/saved_kcl /usr/kcl/unixport/
\(fr)
And move this file to an appropriate command directory, say \(fp)/usr/bin\(fr), so
that all KCL users can access it.
You can use the commands lc and lc1 to invoke the compiler directly from the
shell. The content of lc is:
\(reserve 3)\(fp)
#
echo Compiling $1.lsp
~/unixport/saved_kcl ~/unixport/ $1 $1 U1000
\(fr)
Customize these command files in the same way as for the kcl command file
above.
\(reserve 3)
4. Install the header file
Copy the header file \(fp)cmpinclude.h\(fr) to the standard directory for C include
files, say \(fp)/usr/include\(fr).
\(reserve 5)\(fg)
C.4. Installation of KCL/UST\(set-page pp-install-ust)
\(fr)
\(reserve 3)
1. Prepare a directory (hereafter called \(fi)KCL directory\(fr)) for Kyoto Common
Lisp. In the following examples, we suppose that the KCL directory is
\(fp)/usr/kcl\(fr).
\(reserve 3)
2. Three floppy disks are used for the distribution. Load the floppy disks
to the KCL directory by the multi-volume option of the tar command. (Insert
the first disk to the drive and issue the tar command. Then, you will be
prompted to change the disks.)
\(reserve 3)\(fp)
% pwd
/usr/kcl
% tar xvfBM /dev/rdy0g 1976
\(fr)
You will find that the subdirectory \(fp)unixport\(fr) has been created. The \(fp)unixport\(fr) subdirectory contains everything that is needed to run KCL and
the KCL compiler. Files in this directory are:
\(reserve 2)
Documents:
\(fp)readme\(fr) this file
\(reserve 4)
Executable files:
\(fp)saved_kcl\(fr) the KCL interpreter and compiler
\(fp)ild\(fr) incremental loader
\(fp)trans\(fr) translator from Unix 4.2 to Unix V
\(reserve 4)
Command Source files:
\(fp)kcl.c\(fr) to invoke KCL
\(fp)lc.c\(fr) to invoke the KCL compiler
\(fp)lc1.c\(fr) to invoke the KCL compiler
\(reserve 2)
Header file:
\(fp)cmpinclude.h\(fr) the header file for the KCL compiler
\(reserve 3)
3. Customize the command files.
The source file \(fp)kcl.c\(fr) consists of a C-language program to invoke the KCL
interpreter. Replace all \(fp)/usr/ukcl\(fr) in this file with the pathname of the KCL directory
(i.e., \(fp)/usr/kcl\(fr) in our example), and compile this file.
\(fp)
% cc -o kcl kcl.c
\(fr)
And move the object file to an appropriate command directory, say \(fp)/usr/bin\(fr),
so that all KCL users can access it.
You can use the source files \(fp)lc.c\(fr) and \(fp)lc1.c\(fr) to invoke the compiler directly
from the shell. Customize these source files in the same way as for the kcl command file above.
\(reserve 3)
4. Install the header file
Copy the header file \(fp)cmpinclude.h\(fr) to the standard directory for C include
